Writing an Enigma Simulator |
![]() |
Contents of this page | ![]() |
![]() | |
Introduction | ![]() |
![]() | |
Ever since I first heard about Enigma, I was fascinated by it.
But it was not until I attended a lecture about WWII technology,
that I really wanted to know more about it. After reading
Robert Harris' novel Enigma, I visited Bletchley Park in the
summer of 2001. The trip was worth while and I can recommend
a visit to Bletchley Park to anyone interrested in the matter.
The whole story, from the listening stations at the coast line,
to the actual code breaking, is demonstrated and visitors can
try to decode a 'real' message on one of the Enigmas on display.
The look and feel of the Enigma is rather unique, and the thought that this piece of wood and metal was actually used to encode and decode messages during WWII, makes it even more special. Wouldn't it be nice to have such a unique piece of history for yourself? The only problem here is that the machines are rare these days and that their price is running between GBP 20,000 and GBP 100,000. Nevertheless I wanted to 'have' one, in order to be able to study the coding process used by the Germans during the war and the Bletchley Park efforts to break it. When I came home after the holidays, I searched the Internet for useful Enigma simulations. I found a couple of Java applets, but some of these didn't produce the expected results. Although they explained the working principle of the Enigma, they didn't simulate the actual device. I also found the Enigma Simulations for Windows, by the CSG (the Crypto Simulation Group). These are written by experts on the Enigma subject and produce correct results. The only problem here is that they are running on Windows and not on RISC OS. I then decided to create my own version of the Enigma Simulator especially to run on RISC OS. Paul Reuvers enigma@xat.nl ![]() |
Writing the simulator | ![]() |
![]() | |
Before writing the actual simulator, I had to study the subject
and get to grips with the mechanical functionality of the Enigma.
I read a couple of books and found some interesting documents
on the Internet, most of them written by David Hamer and other
members of the CSG. This documentation was very useful and I
learned that the Enigma is not a single device. In fact, many
variants, both mechanical and electrical exist, and most
of these are not compatible with each other.
In the section below I've tried to explain the working principle of the Enigma and after that, I will try to explain the differences between the various models. In order to produce reliable results, I had to implement the characteristics of each Enigma variant and this has resulted in a set of 'profiles' used to describe each model. To make the simulations more realistic, I've added a texture, or skin, and a realistic sound recorded from a real Enigma by Jim Oram in the USA who is currently building an Enigma-replica. The 'skin' of each model has been carefully deduced from the many pictures in books and on the Internet. If you come across a detailed image that may be of use to me, please feel free to send me a copy by email. For the purpose of studying the working principle, a visual scrambler has been added that will show the flow of the electric current in real time, whenever a button is pressed. Furthermore the full wiring and behaviour of each of the coding wheels of the Enigma can be studied in separate windows. |
Working principle | ![]() |
![]() | |
When studying the working principle of the Enigma, we have to consider
that there are in fact many different variants of this machine.
Some of the differences make it impossible to decrypt a message
that was encoded on another model. That does however not affect the working
principle as explained here. For this we study the circuit diagram
of an Enigma M3.
![]() |
Differences | ![]() |
![]() | |
Looking at the various Enigma variants, a number of differences
have to be noted. These are important as they may affect the application.
The following differences have to be considered:
![]() |
Design considerations | ![]() |
![]() | |
The next thing I had to do, was to decide whether I wanted to simulate
just one Enigma or, if possible, all known models. As there are mechanical
differences between the various models, this will have major consequences for
the application. Another consideration was whether to implement a simple
window, showing just the wheel settings, or a detailed realistic view of
the device.
I decided to take the difficult route and simulate all known models as realistic as possible. The algorithm used to translate the data was setup in a universal manner, with a number of options to indicate the differences in models. Furthermore, a scripting language was defined to describe each model in detail. The main Enigma application will build each model 'on the fly' when loading the script for that model. Once loaded, the Enigma had to be displayed in a window in a layout similar to a real Enigma. Furthermore, key presses should be allowed either from the mouse (by clicking the appropriate key in the display) or the keyboard. Additionally a 'direct text' window should help entering long message without the need to go through the lengthy process of typing and noting down each and every letter. In order to give the Enigma Simulator some educational features, it was thought necessary to display the full wheel wiring in a variety of ways, show exactly how the current flows through the device. To improve even further on the educational side, a user has to be able to save the current settings, which will indeed be very useful for someone doing historical or cryptological research. |
Graphics | ![]() |
![]() | |
A large part of the simulation is taken up by the graphics. The more
realistic these graphics are, the more fun it will be to use the
simulator. Most graphics are created by hand, using ArtWorks, Paint
and Photodesk,
and are converted to 256 colours using ChangeFSI. The reason to use
256 colours, is that it makes a good tradeoff between compatibility
and quality. It can be used on all RISC OS computers, as they are all
capable of displaying 256 colours, whilst it produces an acceptable
graphical quality.
The textured dark metal Enigma case was manipulated many times in Photodesk, until the desired result was achieved. Next the lamps and the keys were drawn, for which a separate BASIC program was written. The program allows various types of keys to be given a fixed set of letters in a variety of ways. Two sets of keys are created in this way, a released and a pressed variant. The same goes for the letters on the lamp panel: one with the lamp off and one with the lamp on for each letter.
Now for the wooden case. Although a minor part of the simulation, it enhances the sense of realism drasticly. I played with various scans and existing sprites, but none of these resulted in the required effect. Finally, I returned to Photodesk and used the invaluable Texture Explorer, which gave me the required effect within minutes. A great deal of time was spent making the animations smoot and realistic. Wheel movements are locked to the internal clock so that they will run at the same speed on all machines. In order to avoid screen flicker the animations are also synchronised with the vertical refresh frequency of the graphics system. Much time has been put in making the screen updates as fast as possible, so that it would perform equally wel on my SA Risc PC as on less powerful systems. The Enigma logo was completely re-created as I couldn't find a high quality version of it. Scanned from the original Enigma manual, enhanced in Paint and converted into Draw using Tracer Professional, simply the best bitmap tracer I've ever seen. The resulting draw file is available for download from the website, in case you want to use it.
![]() |
Sound | ![]() |
![]() | |
Whilst I was working on my Simulator, an Enigma researcher pointed
me to the website of Jim Oram in the US. Jim was working on an Enigma
replica and had detailed knowledge of the mechanics involved. His
website is loaded with high quality photographs of his progress and
even holds a high quality sound sample. The sample was
recorded from a real M4 Enigma in a museum in the US.
Jim was so kind to let me use the sample, which I converted from WAV format into AudioWorks using the CC application !AudioWorks. Parts of this sample were used, converted, enhanced, etc. to create most of the other sound effects. The only simulation which is not accurate, is the Abwehr Enigma (G-model) which produces a different sound due to the difference in its transport mechanism. However, I haven't found anyone to date who can produce a sound sample of an Enigma G... AudioWorks samples are played by the AudioManager module, also created by Computer Concepts (CC). Unfortunately, this module is not 32-bit compatible and can therefore not be used on the new IYONIX pc, using a 32-bit only Intel XScale processor. In the current release, sound has been converted to raw 16-bit format (close to WAV format again) and is played by John Duffel's DataPlayer. ![]() |
Programming language | ![]() |
![]() | |
Enigma is a good example of what can be achieved in BBC BASIC.
Yes, that's right! The entire application is written in BBC BASIC
and is compiled with the invaluable ABC BASIC Compiler. The compler
serves a number of needs. First of all it's a good way to protect
your code and secondly it makes the program quite a lot faster.
In addition to this, memory management is much easier and it takes
the pain out of claiming and releasing blocks of memory.
The ABC compiler is part of the 32-bit Developer Toolkit released
by Castle.
![]() |
Development | ![]() |
![]() | |
During the development of the Enigma Simulator I had a lot of help
from a couple of Enigma researchers, such as David Hamer, Frode Weierud,
Jim Oram, Geoff Sullivan and others. Special thanks go to David Hamer
as he has been patiently answering the many questions I had over a
period of serveral weeks. In the summer of 2002 we finally met, after
hundreds of e-mail messages, at the annual Enigma reunion at Bletchley
Park in the UK and I was able to show him my achievements.
David has kept records of all Enigma wheel wirings found in various places all over the world and many of the wiring tables used in this Simulator were produced by him. A little routine inside the simulator checks the tables for consistency and pointed us to a small number of typos, which were fed back to David. I carefully read all papers produced by David and other researchers to get the grips with the mechanical principles inside the machine and gradually produced my first encrypted messages. It probably won't surprise anyone that the first messages could not be read back due to mistakes in the algorithm... |
My first day as a cryptanalist | ![]() |
![]() | |
Finally, after many days of research and programming, I managed to
encrypt a message that I could decrypt again. This meant that the
algoritm was processing the permutations correctly, but that still
was no guarantee that I could decode real Enigma messages.
Again, David Hamer was able to help me out. He provided me with some
real intercepts (recorded by the listening stations during WWII)
and gave the correct wheel settings to decode the message. However,
he didn't provide the clear text, so I was pretty much left in the
dark.
The first test did not produce any readable text, which put me right back at square one. At least so it seemed for a while. And this is the point where my build-in scrambler window came to the rescue. The scrambler window shows the current flow between the wheels and it clearly showed that it already went wrong at the first wheel. It appeared simple to fix this one; I simply had misinterpreted the way in which the Ringstelung generates an offset. In other words: I was moving the ring in the opposite direction! A simple minus sign was all that was needed to get me going again and minutes later I saw the first readable German text appear:
|
Recommended reading | ![]() |
![]() | |
|
Thanks are due to... | ![]() |
![]() | |
|
© Copyright Paul Reuvers. Last changed: Mon,31 May 2004.09:36:29 | ||
![]() |